Es ist immer befriedigend, leistungsstarke neue Wege zur Problemlösung zu teilen, besonders wenn die Lösung eine Zeit lang "offensichtlich verborgen" war. Dieses Mal zeige ich, wie die Kombination aus ArcGIS Enterprise branch versioning und cloud native data sharing nicht nur schnellen Datenzugriff für Personen ohne Portalzugang ermöglicht, sondern auch die Fähigkeit, die abgerufenen Daten zeitlich zurückreisen zu lassen, als sie noch jünger waren. Wie diese Parzellen, sehen Sie eine zuvor ungeteilte Parzelle und jetzt ihre drei Unterteilungen.<\/P>
Parcel subdivision<\/span><\/span>Parcel subdivision<\/SPAN><\/SPAN><\/SPAN><\/P>Stellen Sie sich einen Datensatz mit Millionen von Features vor, der täglich stark gewartet wird, wie es branch versioning handhabt. Ihre Kunden können jederzeit auf alle oder Teile der Standardversion zugreifen. Für immer. Ohne zusätzliche Belastung Ihres Enterprise-Portals.<\/P>Wie bin ich also darauf gekommen? Ich habe einfach bemerkt, dass das Insert-Only-Transaktionsmodell von branch versioning gut geeignet ist, um GeoParquet-Dateien in Cloud-Speicher inkrementell zu erstellen, die gemeinsam den Datenzustand über die Zeit bewahren und räumlich sowie zeitlich abgefragt werden können, um lokale Daten bei Bedarf für Ihr Gebiet und Ihren Zeitraum bereitzustellen.<\/P>Es ist allerdings eine sehr ausgefeilte Abfrage! Die gute Nachricht ist jedoch, dass Sie sie nicht selbst herausfinden müssen. Der Blog-Download enthält ein Notebook mit Beispielen für mein Parzellenthema – setzen Sie einfach Ihre eigenen Daten ein.<\/P>Ich musste den Abfrageansatz nicht erfinden, Esri veröffentlicht Workshop-Materialien zu diesem Thema. Zum Beispiel sehen Sie bei etwa Minute 18 in dieser Präsentation, wie so eine Abfrage aussieht.<\/P>Spoiler<\/a>die Archivklasse zur Karte hinzufügen, sind sie verfügbar:<\/P>
Archivklasse zur Karte hinzugefügt<\/span><\/span>Archivklasse zur Karte hinzugefügt<\/SPAN><\/SPAN><\/SPAN><\/P>Ein paar Dinge sind im Feldkartenbild zu beachten: ObjectID wird zu einem gewöhnlichen Long Integer degradiert (Werte sind nicht mehr eindeutig) und verschiedene Felder namens GDB_* werden hinzugefügt. Diese ermöglichen das Betrachten der Daten zu einem bestimmten Zeitpunkt, was branch versioning ausmacht – der neueste Zustand eines Features zählt, auch wenn es gelöscht wurde. Die Datenhistorie geht nicht verloren (außer man löscht sie), was Zeitreisen ermöglicht.<\/P>Die Archivklasse ist auch gut geeignet, um herauszufinden, welche Bearbeitungsmomente in Ihren Daten vorhanden sind.<\/P>Mit der Archivklasse als Sichtbarkeit für alle Felder war der Sharing- und Wartungsworkflow möglich. Er läuft folgendermaßen ab:<\/P>Erstellen Sie eine initiale Parquet-Datei mit allen Archivklassenzeilen, bei denen GDB_BRANCH_ID = 0 ist<\/LI>Erstellen Sie nach einem sinnvollen Zeitplan Delta-Parquet-Dateien für neue Standard-Branch-ZuständeDiese haben ein GDB_FROM_DATE später als das Maximum aller vorhandenen Parquet-Dateien<\/LI>Sie haben ebenfalls GDB_BRANCH_ID = 0<\/LI><\/UL><\/LI>Verwalten Sie alle Parquet-Dateien in Ihrem bevorzugten S3-kompatiblen Objektspeicher unter einem globalen Pfad<\/LI>Bieten Sie Ihren Datenkunden ein Notebook oder Skriptwerkzeug an, mit dem sie Daten extrahieren könnenDas bereitgestellte Notebook benötigt DuckDB Version 1.0.0 in der Python-Umgebung<\/LI><\/UL><\/LI><\/UL>Ich bewerbe dies jetzt als cloud native data distribution, aber zum Zeitpunkt des Schreibens richte ich noch mein AWS-Konto ein, daher verwendet das angehängte Notebook einen lokalen Dateisystempfad. Ich werde das aktualisieren, sobald ich eine öffentliche S3-URL habe. In der Zwischenzeit können Sie Beispieldaten zum Testen hier, hier, hier und hier herunterladen. Es handelt sich um die anfängliche Bulk-Versionkopie und einige inkrementelle Delta-Dateien mit jeweils einigen Tagen Bearbeitungen. Ändern Sie die Variable pqPath im Notebook entsprechend Ihrer Umgebung, bis ich den S3-Pfad eingerichtet habe.<\/P>Spoiler<\/A>Die verwendeten Daten werden tatsächlich nicht in einer branch versioned Geodatabase gepflegt. Ich habe Beispieldaten erstellt. Bitte beachten Sie die Datenberechtigungen in den Artikeldetails der obigen Links.<\/DIV>
Die verwendeten Daten werden tatsächlich nicht in einer branch versioned Geodatabase gepflegt. Ich habe Beispieldaten erstellt. Bitte beachten Sie die Datenberechtigungen in den Artikeldetails der obigen Links.<\/DIV><\/DIV>
Im Notebook stelle ich eine Vorlage für Extent- und Zeitreiseabfragen bereit. Ich kann alle 2,7 Millionen Parzellen meiner Daten in etwas mehr als 3 Minuten vom lokalen Laufwerk extrahieren. Der Zugriff von S3 dürfte etwas langsamer sein – wir werden sehen, wenn ich das eingerichtet habe. Probieren Sie das Notebook selbst aus.<\/P>
Vielleicht haben Sie einige Fragen zum Notebook. Ich versuche mal ein paar vorauszusehen:<\/P>
- DuckDB 1.0.0 wird verwendet, da es im Esri Conda-Kanal enthalten ist und spätere Versionen Geometrie anders behandeln<\/LI>
- Die bbox-Spalte in den Parquet-Dateien ist vom JSON-Typ, wird aber als varchar abgefragt, da DuckDB die Daten scheinbar nicht als JSON erkannte<\/LI>
- Ich habe versucht, die eingebaute rowid-Pseudospalte in DuckDB zu verwenden, bekam aber Fehler und habe sie daher überschrieben<\/LI>
- Ich versuchte, die Ausgabefeature-Class über einen spatially enabled dataframe zu schreiben, bekam aber Fehler<\/LI>
- Im Blog-Download hat das Projekt atbx ein Skriptwerkzeug enthalten, mit dem ich gewünschte Textfeldbreiten für Ausgaben ermittelt habe<\/LI><\/UL>
Jetzt werde ich ein wenig egoistisch sein. Um meine Beispieldaten und Parquet-Dateien zu erstellen, habe ich einige ETL-Werkzeuge (Pro 3.4) gebaut, die ich hätte skripten können. Diese Werkzeuge sind nicht im Blog-Download enthalten. Wenn Sie daran interessiert sind, schreiben Sie mir bitte eine Nachricht und ich kann sie teilen. Es hilft dem Team hier sehr zu wissen, wie viele Leute an diesem Data-Sharing-Paradigma interessiert sind – also helfen Sie uns bitte dabei Ihnen zu helfen.<\/P>
